<HTML
><HEAD
><TITLE
>Filesystems</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.63
"><LINK
REL="HOME"
TITLE="The Linux System Administrator's Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="Using Disks and Other Storage Media"
HREF="c955.html"><LINK
REL="PREVIOUS"
TITLE="Partitions"
HREF="x1139.html"><LINK
REL="NEXT"
TITLE="Disks without filesystems"
HREF="x1657.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Linux System Administrator's Guide: Version 0.7</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x1139.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 6. Using Disks and Other Storage Media</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x1657.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN1298"
>6.8. Filesystems</A
></H1
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1300"
>6.8.1. What are filesystems?</A
></H2
><P
>A <I
CLASS="GLOSSTERM"
>filesystem</I
> is the methods and
	data structures that an operating system uses to keep track of files
	on a disk or partition; that is, the way the files are organised on
	the disk.  The word is also used to refer to a partition or disk
	that is used to store the files or the type of the filesystem.
	Thus, one might say ``I have two filesystems'' meaning one has two
	partitions on which one stores files, or that one is using the
	``extended filesystem'', meaning the type of the filesystem.</P
><P
>The difference between a disk or partition and the 
	filesystem it contains is important.  A few programs (including,
	reasonably enough, programs that create filesystems) operate
	directly on the raw sectors of a disk or partition; if there is an
	existing file system there it will be destroyed or seriously
	corrupted.  Most programs operate on a filesystem, and therefore
	won't work on a partition that doesn't contain one (or that contains 
	one of the wrong type).</P
><P
>Before a partition or disk can be used as a filesystem, it
	needs to be initialised, and the bookkeeping data structures need to
	be written to the disk.  This process is called
	<I
CLASS="GLOSSTERM"
>making a filesystem</I
>.</P
><P
>Most UNIX filesystem types have a similar general
	structure, although the exact details vary quite a bit. The central
	concepts are <I
CLASS="GLOSSTERM"
>superblock</I
>,
	<I
CLASS="GLOSSTERM"
>inode</I
>, <I
CLASS="GLOSSTERM"
>data block</I
>,
	<I
CLASS="GLOSSTERM"
>directory block</I
>, and <I
CLASS="GLOSSTERM"
>indirection
	block</I
>.  The superblock contains information about the
	filesystem as a whole, such as its size (the exact information here
	depends on the filesystem).  An inode contains all information about
	a file, except its name.  The name is stored in the directory,
	together with the number of the inode. A directory entry consists of
	a filename and the number of the inode which represents the file.
	The inode contains the numbers of several data blocks, which are
	used to store the data in the file.  There is space only for a few
	data block numbers in the inode, however, and if more are needed,
	more space for pointers to the data blocks is allocated dynamically.
	These dynamically allocated blocks are indirect blocks; the name
	indicates that in order to find the data block, one has to find
	its number in the indirect block first.</P
><P
>UNIX filesystems usually allow one to create a
	<I
CLASS="GLOSSTERM"
>hole</I
> in a file (this is done with the 
	<TT
CLASS="FUNCTION"
>lseek()</TT
> system call; check the manual page),
	which means that the filesystem just pretends that at a particular
	place in the file there is just zero bytes, but no actual disk
	sectors are reserved for that place in the file (this means that the
	file will use a bit less disk space). This happens especially often
	for small binaries, Linux shared libraries, some databases, and a
	few other special cases.  (Holes are implemented by storing a
	special value as the address of the data block in the indirect block
	or inode.  This special address means that no data block is
	allocated for that part of the file, ergo, there is a hole in the 
	file.)</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1316"
>6.8.2. Filesystems galore</A
></H2
><P
>Linux supports several types of filesystems.  As of this
	writing the most important ones are:

	<DIV
CLASS="GLOSSLIST"
><DL
><DT
><B
>minix</B
></DT
><DD
><P
>The oldest, presumed to be the most 
		reliable, but quite limited in features (some time stamps
		are missing, at most 30 character filenames) and restricted
		in capabilities (at most 64 MB per filesystem).
		</P
></DD
><DT
><B
>xia</B
></DT
><DD
><P
>A modified version of the minix filesystem 
		that lifts the limits on the filenames and filesystem sizes,
		but does not otherwise introduce new features.  It is not
		very popular, but is reported to work very well.
		</P
></DD
><DT
><B
>ext2</B
></DT
><DD
><P
>The most featureful of the native Linux 
		filesystems, currently also the most popular one.  It is
		designed to be easily upwards compatible, so that new
		versions of the filesystem code do not require re-making the
		existing filesystems.</P
></DD
><DT
><B
>ext</B
></DT
><DD
><P
>An older version of ext2 that wasn't upwards
		compatible.  It is hardly ever used in new installations any
		more, and most people have converted to ext2.
		</P
></DD
><DT
><B
>reiserfs</B
></DT
><DD
><P
>A more robust filesystem.  Journalling is
		used which makes data loss less likely.  Journalling is a
		mechanism whereby a record is kept of transaction which are
		to be performed, or which have been performed.  This allows
		the filesystem to reconstruct itself fairly easily after
		damage caused by, for example, improper
		shutdowns.</P
></DD
>/glossentry&#62;

	</DL
></DIV
>
	</P
><P
>In addition, support for several foreign filesystem exists,
	to make it easier to exchange files with other operating systems.
	These foreign filesystems work just like native ones, except that
	they may be lacking in some usual UNIX features, or have curious
	limitations, or other oddities.

	<DIV
CLASS="GLOSSLIST"
><DL
><DT
><B
>msdos</B
></DT
><DD
><P
>Compatibility with MS-DOS (and OS/2 and
		Windows NT) FAT filesystems.</P
></DD
><DT
><B
>umsdos</B
></DT
><DD
><P
>Extends the msdos filesystem driver under
		Linux to get long filenames, owners, permissions, links, and
		device files. This allows a normal msdos filesystem to be
		used as if it were a Linux one, thus removing the need for a
		separate partition for Linux.</P
></DD
><DT
><B
>vfat</B
></DT
><DD
><P
>This is an extension of the FAT filesystem
		known as FAT32.  It supports larger disk sizes than FAT.
		Most MS Windows disks are vfat.</P
></DD
><DT
><B
>iso9660</B
></DT
><DD
><P
>The standard CD-ROM filesystem; the popular
		Rock Ridge extension to the CD-ROM standard that allows
		longer file names is supported automatically.
		</P
></DD
><DT
><B
>nfs</B
></DT
><DD
><P
>A networked filesystem that allows sharing a
		filesystem between many computers to allow easy access to
		the files from all of them.</P
></DD
><DT
><B
>smbfs</B
></DT
><DD
><P
>A networks filesystem which allows sharing
		of a filesystem with an MS Windows computer.  It is
		compatible with the Windows file sharing protocols.
		</P
></DD
><DT
><B
>hpfs</B
></DT
><DD
><P
>The OS/2 filesystem.
		</P
></DD
><DT
><B
>sysv</B
></DT
><DD
><P
>SystemV/386, Coherent, and Xenix filesystems.
		</P
></DD
></DL
></DIV
>
	</P
><P
>The choice of filesystem to use depends on the situation.  If
	compatibility or other reasons make one of the non-native
	filesystems necessary, then that one must be used.  If one can
	choose freely, then it is probably wisest to use ext2, since it has
	all the features but does not suffer from lack of performance.</P
><P
>There is also the proc filesystem, usually accessible as
	the <TT
CLASS="FILENAME"
>/proc</TT
> directory, which is not really a
	filesystem at all, even though it looks like one.  The proc
	filesystem makes it easy to access certain kernel data structures,
	such as the process list (hence the name). It makes these data
	structures look like a filesystem, and that filesystem can be
	manipulated with all the usual file tools.  For example, to get a
	listing of all processes one might use the command

<TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>ls -l /proc</B
></TT
>
<TT
CLASS="COMPUTEROUTPUT"
>total 0
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 1
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 63
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 94
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 95
dr-xr-xr-x   4 root     users           0 Jan 31 20:37 98
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 99
-r--r--r--   1 root     root            0 Jan 31 20:37 devices
-r--r--r--   1 root     root            0 Jan 31 20:37 dma
-r--r--r--   1 root     root            0 Jan 31 20:37 filesystems
-r--r--r--   1 root     root            0 Jan 31 20:37 interrupts
-r--------   1 root     root      8654848 Jan 31 20:37 kcore
-r--r--r--   1 root     root            0 Jan 31 11:50 kmsg
-r--r--r--   1 root     root            0 Jan 31 20:37 ksyms
-r--r--r--   1 root     root            0 Jan 31 11:51 loadavg
-r--r--r--   1 root     root            0 Jan 31 20:37 meminfo
-r--r--r--   1 root     root            0 Jan 31 20:37 modules
dr-xr-xr-x   2 root     root            0 Jan 31 20:37 net
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 self
-r--r--r--   1 root     root            0 Jan 31 20:37 stat
-r--r--r--   1 root     root            0 Jan 31 20:37 uptime
-r--r--r--   1 root     root            0 Jan 31 20:37 
version</TT
>
<TT
CLASS="PROMPT"
>$</TT
></PRE
></FONT
></TD
></TR
></TABLE
>

	(There will be a few extra files that don't correspond to
	processes, though.  The above example has been shortened.)</P
><P
>Note that even though it is called a filesystem, no part of 
	the proc filesystem touches any disk.  It exists only in the
	kernel's imagination.  Whenever anyone tries to look at any part of
	the proc filesystem, the kernel makes it look as if the part existed
	somewhere, even though it doesn't.  So, even though there is a
	multi-megabyte <TT
CLASS="FILENAME"
>/proc/kcore</TT
> file, it doesn't
	take any disk space. </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1384"
>6.8.3. Which filesystem should be used?</A
></H2
><P
>There is usually little point in using many different
	filesystems.  Currently, ext2fs is the most popular one, and it is
	probably the wisest choice.  Depending on the overhead for
	bookkeeping structures, speed, (perceived) reliability,
	compatibility, and various other reasons, it may be advisable to use
	another file system.  This needs to be decided on a case-by-case
	basis.
		<A
NAME="AEN1387"
HREF="#FTN.AEN1387"
>[1]</A
>
	</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1389"
>6.8.4. Creating a filesystem</A
></H2
><P
>Filesystems are created, i.e., initialised, with the 
	<B
CLASS="COMMAND"
>mkfs</B
> command.  There is actually a separate
	program for each filesystem type.  <B
CLASS="COMMAND"
>mkfs</B
> is just a
	front end that runs the appropriate program depending on the desired
	filesystem type.  The type is selected with the 
	<TT
CLASS="OPTION"
>-t fstype</TT
> option.</P
><P
>The programs called by <B
CLASS="COMMAND"
>mkfs</B
> have slightly
	different command line interfaces.  The common and most important
	options are summarised below; see the manual pages for more.

	<DIV
CLASS="GLOSSLIST"
><DL
><DT
><B
><TT
CLASS="OPTION"
>-t fstype</TT
></B
></DT
><DD
><P
>		Select the type of the filesystem.
		</P
></DD
><DT
><B
><TT
CLASS="OPTION"
>-c</TT
></B
></DT
><DD
><P
>		 Search for bad blocks and initialise the bad
		block list accordingly.
		</P
></DD
><DT
><B
>-l filename</B
></DT
><DD
><P
>		Read the initial bad block list from the name file.
		</P
></DD
></DL
></DIV
>
	</P
><P
>To create an ext2 filesystem on a floppy, one would give the
	following commands:

<TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>fdformat -n /dev/fd0H1440</B
></TT
>
<TT
CLASS="COMPUTEROUTPUT"
>Double-sided, 80 tracks, 18 sec/track. Total capacity 
1440 kB.
Formatting ... done</TT
>
<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>badblocks /dev/fd0H1440 1440 $&#62;$ 
bad-blocks</B
></TT
>
<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>mkfs -t ext2 -l bad-blocks 
/dev/fd0H1440</B
></TT
>
<TT
CLASS="COMPUTEROUTPUT"
>mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Writing inode tables: done
Writing superblocks and filesystem accounting information: 
done</TT
>
<TT
CLASS="PROMPT"
>$</TT
></PRE
></FONT
></TD
></TR
></TABLE
>

	First, the floppy was formatted (the <TT
CLASS="OPTION"
>-n</TT
> option
	prevents validation, i.e., bad block checking).  Then bad blocks
	were searched with <B
CLASS="COMMAND"
>badblocks</B
>, with the output
	redirected to a file, <TT
CLASS="FILENAME"
>bad-blocks</TT
>.	Finally, the
	filesystem was created, with the bad block list initialised
	by whatever <B
CLASS="COMMAND"
>badblocks</B
> found.</P
><P
>The <TT
CLASS="OPTION"
>-c</TT
> option could have been used with
	<B
CLASS="COMMAND"
>mkfs</B
> instead of <B
CLASS="COMMAND"
>badblocks</B
>
	and a separate file.  The example below does that.

<TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>mkfs -t ext2 -c 
/dev/fd0H1440</B
></TT
>
<TT
CLASS="COMPUTEROUTPUT"
>mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Checking for bad blocks (read-only test): done
Writing inode tables: done
Writing superblocks and filesystem accounting information: 
done</TT
>
<TT
CLASS="PROMPT"
>$</TT
></PRE
></FONT
></TD
></TR
></TABLE
>

	The <TT
CLASS="OPTION"
>-c</TT
> option is more convenient than a separate 
	use of <B
CLASS="COMMAND"
>badblocks</B
>, but
	<B
CLASS="COMMAND"
>badblocks</B
> is necessary for checking
	after the filesystem has been created.</P
><P
>The process to prepare filesystems on hard disks or
	partitions is the same as for floppies, except that the formatting
	isn't needed.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="MOUNT-AND-UMOUNT"
>6.8.5. Mounting and unmounting</A
></H2
><P
>Before one can use a filesystem, it has to be 
	<I
CLASS="GLOSSTERM"
>mounted</I
>. The operating system then does
	various bookkeeping things to make sure that everything works. Since
	all files in UNIX are in a single directory tree, the mount
	operation will make it look like the contents of the new filesystem
	are the contents of an existing subdirectory in some already mounted
	filesystem.</P
><P
>For example, <A
HREF="x1298.html#HD-MOUNT-ROOT"
>Figure 6-3</A
> shows three
	separate filesystems, each with their own root directory. When the
	last two filesystems are mounted below <TT
CLASS="FILENAME"
>/home</TT
>
	and <TT
CLASS="FILENAME"
>/usr</TT
>, respectively, on the first 
	filesystem, we can get a single directory tree, as in
	<A
HREF="x1298.html#HD-MOUNT-ALL"
>Figure 6-4</A
>.</P
><DIV
CLASS="FIGURE"
><A
NAME="HD-MOUNT-ROOT"
></A
><P
><B
>Figure 6-3. Three separate filesystems.</B
></P
><P
><IMG
SRC="hd-mount-separate.gif"></P
></DIV
><DIV
CLASS="FIGURE"
><A
NAME="HD-MOUNT-ALL"
></A
><P
><B
>Figure 6-4. <TT
CLASS="FILENAME"
>/home</TT
> and <TT
CLASS="FILENAME"
>/usr</TT
> 
		have been 
		mounted.</B
></P
><P
><IMG
SRC="hd-mount-mounted.gif"></P
></DIV
><P
>The mounts could be done as in the following example:

<TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>mount /dev/hda2 /home</B
></TT
>
<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>mount /dev/hda3 /usr</B
></TT
>
<TT
CLASS="PROMPT"
>$</TT
></PRE
></FONT
></TD
></TR
></TABLE
>

	The <B
CLASS="COMMAND"
>mount</B
> command takes two arguments. The first
	one is the device file corresponding to the disk or partition
	containing the filesystem.  The second one is the directory below
	which it will be mounted.  After these commands the contents of the
	two filesystems look just like the contents of the
	<TT
CLASS="FILENAME"
>/home</TT
> and <TT
CLASS="FILENAME"
>/usr</TT
>
	directories, respectively.  One would then say that
	``<TT
CLASS="FILENAME"
>/dev/hda2</TT
> <I
CLASS="GLOSSTERM"
>is mounted
	on</I
> <TT
CLASS="FILENAME"
>/home</TT
>'', and similarly for
	<TT
CLASS="FILENAME"
>/usr</TT
>.  To look at either filesystem, one would
	look at the contents of the directory on which it has been mounted,
	just as if it were any other directory.  Note the difference between
	the device file, <TT
CLASS="FILENAME"
>/dev/hda2</TT
>, and the mounted-on
	directory, <TT
CLASS="FILENAME"
>/home</TT
>.  The device file gives access
	to the raw contents of the disk, the mounted-on directory gives
	access to the files on the disk.  The mounted-on directory is called
	the <I
CLASS="GLOSSTERM"
>mount point</I
>.</P
><P
>Linux supports many filesystem types.  
	<B
CLASS="COMMAND"
>mount</B
> tries to guess the type of the filesystem.
	You can also use the <TT
CLASS="OPTION"
>-t fstype</TT
> option to specify
	the type directly; this is sometimes necessary, since the heuristics
	<B
CLASS="COMMAND"
>mount</B
> uses do not always work.  For example, to
	mount an MS-DOS floppy, you could use the following command:

        <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>	<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>mount -t msdos /dev/fd0 
	/floppy</B
></TT
>
	<TT
CLASS="PROMPT"
>$</TT
>
	</PRE
></FONT
></TD
></TR
></TABLE
>
	
	</P
><P
>The mounted-on directory need not be empty, although it
	must exist.  Any files in it, however, will be inaccessible by name
	while the filesystem is mounted.  (Any files that have already been
	opened will still be accessible.  Files that have hard links from
	other directories can be accessed using those names.) There is no
	harm done with this, and it can even be useful.  For instance, some
	people like to have <TT
CLASS="FILENAME"
>/tmp</TT
> and
	<TT
CLASS="FILENAME"
>/var/tmp</TT
> synonymous, and make 
	<TT
CLASS="FILENAME"
>/tmp</TT
> be a symbolic link to
	<TT
CLASS="FILENAME"
>/var/tmp</TT
>.	When the system is booted, before
	the <TT
CLASS="FILENAME"
>/var</TT
> filesystem is mounted, a 
	<TT
CLASS="FILENAME"
>/var/tmp</TT
> directory residing on the root
	filesystem is used instead.  When <TT
CLASS="FILENAME"
>/var</TT
> is
	mounted, it will make the <TT
CLASS="FILENAME"
>/var/tmp</TT
> directory 
	on the root filesystem inaccessible.  If
	<TT
CLASS="FILENAME"
>/var/tmp</TT
> didn't exist on the root filesystem,
	it would be impossible to use temporary files
	before mounting <TT
CLASS="FILENAME"
>/var</TT
>.</P
><P
>If you don't intend to write anything to the filesystem, use
	the <TT
CLASS="OPTION"
>-r</TT
> switch for <B
CLASS="COMMAND"
>mount</B
> to do a 
	<I
CLASS="GLOSSTERM"
>read-only mount</I
>.  This will make the kernel
	stop any attempts at writing to the filesystem, and will also stop
	the kernel from updating file access times in the inodes.  Read-only
	mounts are necessary for unwritable media, e.g., CD-ROMs.</P
><P
>The alert reader has already noticed a slight
	logistical problem.  How is the first filesystem (called the 
	<I
CLASS="GLOSSTERM"
>root filesystem</I
>, because it contains the root
	directory) mounted, since it obviously can't be mounted on another
	filesystem? Well, the answer is that it is done by magic.
	
		<A
NAME="AEN1499"
HREF="#FTN.AEN1499"
>[2]</A
>
		
	The root filesystem is magically mounted at boot time, and one can
	rely on it to always be mounted. If the root filesystem can't be
	mounted, the system does not boot. The name of the filesystem that
	is magically mounted as root is either compiled into the kernel, or
	set using LILO or <B
CLASS="COMMAND"
>rdev</B
>.</P
><P
>The root filesystem is usually first mounted read-only.
	The startup scripts will then run <B
CLASS="COMMAND"
>fsck</B
> to verify
	its validity, and if there are no problems, they will
	<I
CLASS="GLOSSTERM"
>re-mount</I
> it so that writes will also be
	allowed.  <B
CLASS="COMMAND"
>fsck</B
> must not be run on a mounted
	filesystem, since any changes to the filesystem while
	<B
CLASS="COMMAND"
>fsck</B
> is running <EM
>will</EM
> cause
	trouble. Since the root filesystem is mounted read-only while
	it is being checked, <B
CLASS="COMMAND"
>fsck</B
> can fix any problems
	without worry, since the remount operation will flush
	any metadata that the filesystem keeps in memory.</P
><P
>On many systems there are other filesystems that should
	also be mounted automatically at boot time.  These are specified
	in the <TT
CLASS="FILENAME"
>/etc/fstab</TT
> file; see the fstab man
	page for details on the format.  The details of exactly when the
	extra filesystems are mounted depend on many factors, and can be
	configured by each administrator if need be; see
	<A
HREF="boots-and-shutdowns.html"
>Chapter 8</A
>.</P
><P
>When a filesystem no longer needs to be mounted, it can be
	unmounted with <B
CLASS="COMMAND"
>umount</B
>.
	
		<A
NAME="AEN1514"
HREF="#FTN.AEN1514"
>[3]</A
>
		
	<B
CLASS="COMMAND"
>umount</B
> takes one argument:
	either the device file or the mount point.  
	For example, to unmount the directories of
	the previous example, one could use the commands

<TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>umount /dev/hda2</B
></TT
>
<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>umount /usr</B
></TT
>
<TT
CLASS="PROMPT"
>$</TT
></PRE
></FONT
></TD
></TR
></TABLE
>
	</P
><P
>See the man page for further instructions on how to
	use the command.  It is imperative that you always unmount a mounted
	floppy.  <EM
>Don't just pop the floppy out of the
	drive!</EM
> Because of disk caching, the data is not
	necessarily written to the floppy until you unmount it, so removing
	the floppy from the drive too early might cause the contents to
	become garbled.  If you only read from the floppy, this is not very
	likely, but if you write, even accidentally,
	the result may be catastrophic.</P
><P
>Mounting and unmounting requires super user privileges, i.e.,
	only root can do it.  The reason for this is that if any user can
	mount a floppy on any directory, then it is rather easy to create a
	floppy with, say, a Trojan horse disguised as
	<TT
CLASS="FILENAME"
>/bin/sh</TT
>, or any other often used program.  
	However, it is often necessary to allow users to use floppies, and
	there are several ways to do this:

	<P
></P
><UL
><LI
><P
>Give the users the root password.  This is
	obviously bad security, but is the easiest solution.  It works well
	if there is no need for security anyway, which is the case
	on many non-networked, personal systems.</P
></LI
><LI
><P
>Use a program such as <B
CLASS="COMMAND"
>sudo</B
> to 
	allow users to use mount.  This is still bad security, but doesn't
	directly give super user privileges to everyone.
		
		<A
NAME="AEN1534"
HREF="#FTN.AEN1534"
>[4]</A
>
	
	</P
></LI
><LI
><P
>Make the users use <B
CLASS="COMMAND"
>mtools</B
>, a 
	package for manipulating MS-DOS filesystems, without mounting them.
	This works well if MS-DOS floppies are all that is needed, but is
	rather awkward otherwise.
	</P
></LI
><LI
><P
>List the floppy devices and their allowable mount 
	points together with the suitable options in 
	<TT
CLASS="FILENAME"
>/etc/fstab</TT
>.

	</P
></LI
></UL
>

	The last alternative can be implemented by adding a line like the
	following to the <TT
CLASS="FILENAME"
>/etc/fstab</TT
> file:

        <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>	/dev/fd0            /floppy      msdos   user,noauto      0     0
	</PRE
></FONT
></TD
></TR
></TABLE
>

	The columns are: device file to mount, directory to mount on,
	filesystem type, options, backup frequency (used by
	<B
CLASS="COMMAND"
>dump</B
>), and <B
CLASS="COMMAND"
>fsck</B
> pass number
	(to specify the order in which filesystems should be checked
	upon boot; 0 means no check).</P
><P
>The <TT
CLASS="OPTION"
>noauto</TT
> option stops this mount to be done
	automatically when the system is started (i.e., it stops
	<B
CLASS="COMMAND"
>mount -a</B
> from mounting it).  The 
	<TT
CLASS="OPTION"
>user</TT
> option allows any user to mount the
	filesystem, and, because of security reasons, disallows execution of
	programs (normal or setuid) and interpretation of device files from
	the mounted filesystem. After this, any user can mount a floppy with
	an msdos filesystem with the following command:

        <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>	<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>mount /floppy</B
></TT
>
	<TT
CLASS="PROMPT"
>$</TT
>
	</PRE
></FONT
></TD
></TR
></TABLE
>

	The floppy can (and needs to, of course) be unmounted with
	the corresponding <B
CLASS="COMMAND"
>umount</B
> command.</P
><P
>If you want to provide access to several types of floppies,
	you need to give several mount points.  The settings can be
	different for each mount point.  For example, to give access to both
	MS-DOS and ext2 floppies, you could have the following to lines in
	<TT
CLASS="FILENAME"
>/etc/fstab</TT
>:

        <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>	/dev/fd0    /dosfloppy    msdos   user,noauto  0  0
	/dev/fd0    /ext2floppy   ext2    user,noauto  0  0
	</PRE
></FONT
></TD
></TR
></TABLE
>

	For MS-DOS filesystems (not just floppies), you probably want to
	restrict access to it by using the <TT
CLASS="OPTION"
>uid</TT
>,
	<TT
CLASS="OPTION"
>gid</TT
>, and <TT
CLASS="OPTION"
>umask</TT
> filesystem options,
	described in detail on the <B
CLASS="COMMAND"
>mount</B
> manual page.  If
	you aren't careful, mounting an MS-DOS filesystem gives everyone at
	least read access to the files in it, which
	is not a good idea.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1563"
>6.8.6. Checking filesystem integrity with 
<B
CLASS="COMMAND"
>fsck</B
></A
></H2
><P
>Filesystems are complex creatures, and as such, they
	tend to be somewhat error-prone.  A filesystem's correctness and
	validity can be checked using the <B
CLASS="COMMAND"
>fsck</B
> command.
	It can be instructed to repair any minor problems it finds, and to
	alert the user if there any unrepairable problems.  Fortunately, the
	code to implement filesystems is debugged quite effectively, so
	there are seldom any problems at all, and they are usually caused by
	power failures, failing hardware, or operator errors;
	for example, by not shutting down the system properly.</P
><P
>Most systems are setup to run <B
CLASS="COMMAND"
>fsck</B
>
	automatically at boot time, so that any errors are detected (and
	hopefully corrected) before the system is used.  Use of a corrupted
	filesystem tends to make things worse: if the data structures are
	messed up, using the filesystem will probably mess them up even
	more, resulting in more data loss. However, <B
CLASS="COMMAND"
>fsck</B
>
	can take a while to run on big filesystems, and since errors almost
	never occur if the system has been shut down properly, a couple of
	tricks are used to avoid doing the checks in such cases.  The first
	is that if the file <TT
CLASS="FILENAME"
>/etc/fastboot</TT
> exists, no
	checks are made.  The second is that the ext2 filesystem has a
	special marker in its superblock that tells whether the filesystem
	was unmounted properly after the previous mount.  This allows
	<B
CLASS="COMMAND"
>e2fsck</B
> (the version of <B
CLASS="COMMAND"
>fsck</B
>
	for the ext2 filesystem) to avoid checking the filesystem if the
	flag indicates that the unmount was done (the assumption being that
	a proper unmount indicates no problems).  Whether the
	<TT
CLASS="FILENAME"
>/etc/fastboot</TT
> trick works on your system
	depends on your startup scripts, but the ext2 trick works every time
	you use <B
CLASS="COMMAND"
>e2fsck</B
>. It has to be explicitly bypassed
	with an option to <B
CLASS="COMMAND"
>e2fsck</B
> to be avoided.	(See
	the <B
CLASS="COMMAND"
>e2fsck</B
> man page for
	details on how.)</P
><P
>The automatic checking only works for the
	filesystems that are mounted automatically at boot time. Use
	<B
CLASS="COMMAND"
>fsck</B
> manually to check other filesystems,
	e.g., floppies.</P
><P
>If <B
CLASS="COMMAND"
>fsck</B
> finds unrepairable problems,
	you need either in-depth knowledge of how filesystems work in
	general, and the type of the corrupt filesystem in particular, or
	good backups.  The latter is easy (although sometimes tedious) to
	arrange, the former can sometimes be arranged via a friend, the
	Linux newsgroups and mailing lists, or some other source of support,
	if you don't have the know-how yourself.  I'd like to tell you more
	about it, but my lack of education and experience in this regard
	hinders me.  The <B
CLASS="COMMAND"
>debugfs</B
>
	program by Theodore Ts'o should be useful.</P
><P
><B
CLASS="COMMAND"
>fsck</B
> must only be run on unmounted
	filesystems, never on mounted filesystems (with the exception of the
	read-only root during startup).  This is because it accesses the raw
	disk, and can therefore modify the filesystem without the operating
	system realizing it.	There <EM
>will</EM
>
	be trouble, if the operating system is confused.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1586"
>6.8.7. Checking for disk errors with <B
CLASS="COMMAND"
>badblocks</B
></A
></H2
><P
>It can be a good idea to periodically check for bad blocks.
	This is done with the <B
CLASS="COMMAND"
>badblocks</B
> command.  It 
	outputs a list of the numbers of all bad blocks it can find.  This
	list can be fed to <B
CLASS="COMMAND"
>fsck</B
> to be recorded in the
	filesystem data structures so that the operating system won't try to
	use the bad blocks for storing data. The following example will show
	how this could be done.

        <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>	<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>badblocks /dev/fd0H1440 1440 &#62; 
	bad-blocks</B
></TT
>
	<TT
CLASS="PROMPT"
>$</TT
> <TT
CLASS="USERINPUT"
><B
>fsck -t ext2 -l bad-blocks 
	/dev/fd0H1440</B
></TT
>
	<TT
CLASS="COMPUTEROUTPUT"
>Parallelising fsck version 0.5a (5-Apr-94)
	e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
	Pass 1: Checking inodes, blocks, and sizes
	Pass 2: Checking directory structure
	Pass 3: Checking directory connectivity
	Pass 4: Check reference counts.
	Pass 5: Checking group summary information.
	
	/dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED *****
	/dev/fd0H1440: 11/360 files, 63/1440 blocks</TT
>
	<TT
CLASS="PROMPT"
>$</TT
>
	</PRE
></FONT
></TD
></TR
></TABLE
>

	If badblocks reports a block that was already used,
	<B
CLASS="COMMAND"
>e2fsck</B
> will try to move the block to another
	place.	If the block was really bad, not just marginal, the
	contents of the file may be corrupted.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1600"
>6.8.8. Fighting fragmentation</A
></H2
><P
>When a file is written to disk, it can't always be written
	in consecutive blocks.  A file that is not stored in consecutive
	blocks is <I
CLASS="GLOSSTERM"
>fragmented</I
>.  It takes longer to
	read a fragmented file, since the disk's read-write head will have
	to move more.  It is desirable to avoid fragmentation, although it
	is less of a problem in a system with a good buffer
	cache with read-ahead.</P
><P
>The ext2 filesystem attempts to keep fragmentation at a
	minimum, by keeping all blocks in a file close together, even if
	they can't be stored in consecutive sectors.  Ext2 effectively
	always allocates the free block that is nearest to other blocks in a
	file.  For ext2, it is therefore seldom necessary to worry about
	fragmentation.  There is a program for defragmenting an ext2
	filesystem called, strangely enough, <B
CLASS="COMMAND"
>defrag</B
>
		
		<A
NAME="AEN1606"
HREF="#FTN.AEN1606"
>[5]</A
>
	.</P
><P
>There are many MS-DOS defragmentation programs that
	move blocks around in the filesystem to remove fragmentation. For
	other filesystems, defragmentation must be done by backing up the
	filesystem, re-creating it, and restoring the files from backups.
	Backing up a filesystem before defragmenting is a good idea for all
	filesystems, since many things can go wrong
	during the defragmentation.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1610"
>6.8.9. Other tools for all filesystems</A
></H2
><P
>Some other tools are also useful for managing filesystems.
	<B
CLASS="COMMAND"
>df</B
> shows the free disk space on one or more
	filesystems; <B
CLASS="COMMAND"
>du</B
> shows how much disk space a
	directory and all its files contain.  These can be used to hunt down
	disk space wasters.  Both have manual pages which detail
	the (many) options which can be used.</P
><P
><B
CLASS="COMMAND"
>sync</B
> forces all unwritten blocks
	in the buffer cache (see <A
HREF="buffer-cache.html"
>Section 7.6</A
>) to be
	written to disk.  It is seldom necessary to do this by hand; the
	daemon process <B
CLASS="COMMAND"
>update</B
> does this automatically.
	It can be useful in catastrophes, for example if
	<B
CLASS="COMMAND"
>update</B
> or its helper process
	<B
CLASS="COMMAND"
>bdflush</B
> dies, or if you must turn off power
	<EM
>now</EM
> and can't wait for
	<B
CLASS="COMMAND"
>update</B
> to run.  Again, there are manual pages.
	The <B
CLASS="COMMAND"
>man</B
> is your very best friend in linux.  Its
	cousin <B
CLASS="COMMAND"
>apropos</B
> is also very useful when you don't
	know what the name of the command you want
	is.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1625"
>6.8.10. Other tools for the ext2 filesystem</A
></H2
><P
>In addition to the filesystem creator 
	(<B
CLASS="COMMAND"
>mke2fs</B
>) and checker (<B
CLASS="COMMAND"
>e2fsck</B
>)
	accessible directly or via the filesystem type independent front
	ends, the ext2
	filesystem has some additional tools that can be useful.</P
><P
><B
CLASS="COMMAND"
>tune2fs</B
> adjusts filesystem parameters.  
	Some of the more interesting parameters are:

	<P
></P
><UL
><LI
><P
>	A maximal mount count.  <B
CLASS="COMMAND"
>e2fsck</B
> enforces a check 
	when filesystem has been mounted too many times, even if the clean
	flag is set.  For a system that is used for developing or testing
	the system, it might be a good idea to reduce this limit.
	</P
></LI
><LI
><P
>	A maximal time between checks.  <B
CLASS="COMMAND"
>e2fsck</B
> can also 
	enforce a maximal time between two checks, even if the clean flag is
	set, and the filesystem hasn't been mounted very often.  This can be
	disabled, however.
	</P
></LI
><LI
><P
>	Number of blocks reserved for root.  Ext2 reserves some blocks for
	root so that if the filesystem fills up, it is still possible to do
	system administration without having to delete anything.  The
	reserved amount is by default 5 percent, which on most disks isn't
	enough to be wasteful.  However, for floppies there is no point in
	reserving any blocks.
	</P
></LI
></UL
>
	
	See the <B
CLASS="COMMAND"
>tune2fs</B
> manual page for more
	information.</P
><P
><B
CLASS="COMMAND"
>dumpe2fs</B
> shows information about an ext2 
	filesystem, mostly from the superblock.  <A
HREF="x1298.html#DUMPE2FS-OUTPUT"
>Figure 6-5</A
> shows a sample output.  Some of the
	information in the output is technical and requires understanding of
	how the filesystem works (see appendix XXX ext2fspaper), but much of
	it is readily understandable even for layadmins.</P
><DIV
CLASS="FIGURE"
><A
NAME="DUMPE2FS-OUTPUT"
></A
><P
><B
>Figure 6-5. Sample output from <B
CLASS="COMMAND"
>dumpe2fs</B
></B
></P
><P
CLASS="LITERALLAYOUT"
>dumpe2fs&nbsp;0.5b,&nbsp;11-Mar-95&nbsp;for&nbsp;EXT2&nbsp;FS&nbsp;0.5a,&nbsp;94/10/23<br>
Filesystem&nbsp;magic&nbsp;number:&nbsp;&nbsp;0xEF53<br>
Filesystem&nbsp;state:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;clean<br>
Errors&nbsp;behavior:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Continue<br>
Inode&nbsp;count:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;360<br>
Block&nbsp;count:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1440<br>
Reserved&nbsp;block&nbsp;count:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;72<br>
Free&nbsp;blocks:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1133<br>
Free&nbsp;inodes:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;326<br>
First&nbsp;block:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1<br>
Block&nbsp;size:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1024<br>
Fragment&nbsp;size:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1024<br>
Blocks&nbsp;per&nbsp;group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8192<br>
Fragments&nbsp;per&nbsp;group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8192<br>
Inodes&nbsp;per&nbsp;group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;360<br>
Last&nbsp;mount&nbsp;time:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tue&nbsp;Aug&nbsp;&nbsp;8&nbsp;01:52:52&nbsp;1995<br>
Last&nbsp;write&nbsp;time:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tue&nbsp;Aug&nbsp;&nbsp;8&nbsp;01:53:28&nbsp;1995<br>
Mount&nbsp;count:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br>
Maximum&nbsp;mount&nbsp;count:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;20<br>
Last&nbsp;checked:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tue&nbsp;Aug&nbsp;&nbsp;8&nbsp;01:06:31&nbsp;1995<br>
Check&nbsp;interval:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0<br>
Reserved&nbsp;blocks&nbsp;uid:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;(user&nbsp;root)<br>
Reserved&nbsp;blocks&nbsp;gid:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;(group&nbsp;root)<br>
<br>
Group&nbsp;0:<br>
&nbsp;&nbsp;Block&nbsp;bitmap&nbsp;at&nbsp;3,&nbsp;Inode&nbsp;bitmap&nbsp;at&nbsp;4,&nbsp;Inode&nbsp;table&nbsp;at&nbsp;5<br>
&nbsp;&nbsp;1133&nbsp;free&nbsp;blocks,&nbsp;326&nbsp;free&nbsp;inodes,&nbsp;2&nbsp;directories<br>
&nbsp;&nbsp;Free&nbsp;blocks:&nbsp;307-1439<br>
&nbsp;&nbsp;Free&nbsp;inodes:&nbsp;35-360</P
></DIV
><P
><B
CLASS="COMMAND"
>debugfs</B
> is a filesystem debugger.
	It allows direct access to the filesystem data structures stored on
	disk and can thus be used to repair a disk that is so broken that
	<B
CLASS="COMMAND"
>fsck</B
> can't fix it automatically. It has also been
	known to be used to recover deleted files. However,
	<B
CLASS="COMMAND"
>debugfs</B
> very much requires that you understand
	what you're doing; a failure to understand can
	destroy all your data.</P
><P
><B
CLASS="COMMAND"
>dump</B
> and <B
CLASS="COMMAND"
>restore</B
> can be 
	used to back up an ext2 filesystem.  They are ext2 specific versions
	of the traditional UNIX backup tools.  See <A
HREF="backups.html"
>Chapter 12</A
>
	for more information on backups.</P
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1387"
HREF="x1298.html#AEN1387"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Currently there are several filesystems vying
		for replacement of ext2, these include reiserfs and ext3.
		They include ``journalling''.  A definition and explanation
		of journalling is outside the (current) scope of this book,
		but put very simply it is a mechanism whereby the filesystem
		is more robust against power failure, or other inelegant
		shutdowns.  This makes data loss far less likely and so not
		surprisingly it is looking like it will be the standard
		in Linux filesystems eventually.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1499"
HREF="x1298.html#AEN1499"
>[2]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>For more
		information, see the kernel source or the Kernel Hackers'
		Guide.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1514"
HREF="x1298.html#AEN1514"
>[3]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>It should of course be
		<B
CLASS="COMMAND"
>unmount</B
>, but the n mysteriously disappeared in
		the 70s, and hasn't been seen since.  Please return it to Bell
		Labs, NJ, if you find it.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1534"
HREF="x1298.html#AEN1534"
>[4]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>It requires several seconds of hard
		thinking on the users' behalf.  Furthermore
		<B
CLASS="COMMAND"
>sudo</B
> can be configured to only allow
		users to execute certain commands.  See the sudo(8),
		sudoers(5), and visudo(8) manual pages.
		</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1606"
HREF="x1298.html#AEN1606"
>[5]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>		<A
HREF="http://www.go.dlr.de/linux/src/defrag-0.73.tar.gz"
TARGET="_top"
>		http://www.go.dlr.de/linux/src/defrag-0.73.tar.gz</A
>
		</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x1139.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x1657.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Partitions</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c955.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Disks without filesystems</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>